I think we should first separate a kernel-writing issue from a compiler lowering issue here.

For each accumulator, the VMI semantics are already a 1 x T -> 1 reduction:

red = pto.vmi.vcadd(acc_v, mask_t, reassoc=True)
pto.vmi.vstore(red, reduced, i, mask1)

vcadd already returns one logical value. Since the next consumer is only a store, broadcasting that value back to 8 lanes and writing a padded [N_ACC, 8] buffer is not semantically required:

red = pto.vmi.vcadd(acc_v, mask_t, reassoc=True)
padded = pto.vmi.vbrc(red, size=8)
pto.vmi.vstore(padded, reduced_pad, i * 8, mask8)

I tested a self-contained direct vcadd -> mask1 vstore kernel with the current PTOAS build and CANN 9.0. It lowers through VPTO/LLVM IR and Bisheng produces a device object, without pad-8 staging.

The current lowering is still not ideal: the direct form becomes roughly

vcadd
vdup 0
vadd PAT_VL1
predicate materialization
masked vsts

instead of the CCE vcadd + ONEPT store sequence. That may be a valid lowering optimization, but it is different from saying VMI cannot express or compile the compact result.

Could we add the following three-way measurement before attributing the whole gap to missing ONEPT support?

1. current pad-8 workaround;
2. direct 1 x T reduce -> mask1 store with a compact [N_ACC] output;
3. CCE vcadd + ONEPT baseline.

This would tell us how much of the reported gap comes from the padded kernel formulation and how much remains in PTOAS lowering.

2. direct 1 x T reduce -> mask1 store with a compact [N_ACC] output;

I already tried this in this commit, "VMI mask1" variant, still much slower than CCE ONEPT store...

Added a more focused commit 8f321ea here, not much faster than pad8, still need ONEPT scalar store in ptoas vmi.

@mouliangyu

group=1 works c5345df